A typical DCN comprises an Operational Support System (OSS) arranged for managing a plurality of Gateway Network Elements (Gateway NEs), each Gateway Network being arranged for subtending a number of Network Elements (subtended NEs). In this respect, the subtended Network Elements are arranged at a lower hierarchical networked level than the respective Gateway Network Element, such that the subtended Network Elements are interconnected to the DCN via an Ethernet Interface (Gateway NE). The network elements may also be connected via embedded channels inside the traffic lines such as Synchronous Transmission Module-n (STM-n) for Synchronous Digital Hierarchy (SDH) or optical channels for Dense Wavelength Divisional Multiplexing (DWDM). These embedded channels are called, depending from the kind of frame overhead they use, Data Communications Channels (DCCs), Optical Supervisory Channels (OSCs), General Communications Channels (GCCs), and others.
For protection purpose, several DCC channels can be activated between nodes flowing same or separated optical links, and the routing algorithm metrics will allow the proper routing path selection. The same configuration policy is used for DWDM, which deploys OSC for the embedded channels, and for Ethernet links, where a specific Virtual Local Area Network (VLAN) tag is used to carry management data.
If functioning under normal operating conditions, the Network Element management from the OSS ensures that the network is able respond at nearly real-time to a given task. If, however, there is a problem with a Network Element, then the Network Element will send an alarm trap notification to the OSS to notify the OSS of the problem. The capability of the Operational Support System (OSS) to receive alarm traps from the managed Network Elements is a key feature in the monitoring of the network. It allows the operator to take the appropriate actions required to ensure optimal network performance and preserve business. In the event of a high alarm condition, a Network Element or a plurality of Network Elements may send a large number of alarm traps to the Operational Support System.
It will be appreciated that the Operational Support System is only capable of processing alarm trap notifications at a certain rate, and that the Operational Support System will be overloaded if the actual rate of alarm trap notifications exceeds this maximum rate (so-called “Trap Storms”). Accordingly, it is desirable to limit the rate at which alarm traps are sent.
In order to limit the rate at which alarm traps are sent, it is known to allocate a Notification Throttling Threshold to each Network Element. It will be appreciated that if the Throttling Threshold is set too high then an alarm burst may occur, this alarm burst potentially exceeding the capacity of the receiving Network Manager and this incapacitating the network. If, however, the threshold is set too low then it can cause the Network Element to unnecessarily cease its transmission of alarm trap notifications.
One existing technology for limiting the rate at which alarm traps are sent is based on a notification throttling mechanism that enables a customer to allocate a Throttling Threshold to each Network Element. The Throttling Threshold may be based on the Network Element's software and hardware features. The throttling mechanism discards any alarm traps that exceed the customer configurable threshold and the Management System of the OSS polls the Network Element to discover any lost alarms from the alarm log (a so-called “trap recovery mechanism”). One problem with this existing technology is that, in the case of a connectionless algorithm (e.g. SNMP) the trap recovery mechanism will be activated as soon as the next notifications are received causing an unnecessary network overload due to alarm realignment. Another problem is that Network Elements are treated as stand-along elements and their role within the network is not considered. In particular, the problem of a communication bottleneck at the Gateway Network Element is not addressed. In particular, a customer may set the Notification Throttling Threshold for a Network Element appropriately for a given network configuration, but if the configuration of the network is subsequently changed (e.g. a Network Element may go offline) then the previously set Throttling Threshold is no longer suitable.